Is there a way to default the access on new views to 'inherit access from parent'?
Alternative is to run a script periodically to fix the access, but it would be nice if there was a way to make this the default behavior.
Any help is appreciated.
Thanks,
Daniel Mott
DanMott - Wed Sep 28 16:16:51 EDT 2011 |
|
Re: inherit access from parent setting for views
kbmurphy - Wed Sep 28 17:46:37 EDT 2011
I thought View->Save As... and choosing "Custom" set the view to inherit access from the current view. I'm guessing you want "Inherit Access" from the module access rights.
Anyhow, I hate the View>Save As... dialog box and created a better inferface. You can check out my Simple Save View script here:
http://www.baselinesinc.com/?page_id=11&filerepoaction=showpost&filepost_id=1
Feel free to modify it to do what you want it to do (I think some of the behavior of the script has changed between DOORS 8.2 the version it was written for and 9.3)...this is a good starting point, and I'd be happy to merge in your changes if you update it.
Kevin
|
|
Re: inherit access from parent setting for views
llandale - Tue Oct 04 12:02:16 EDT 2011
The clumsy "private" or "public" or "custom" settings are yes inadequate. When someone saves a new view they should immediately manage views, get that view, and adjust its accesses, usually adding the DB and Project admins. But they could also set it to be inherited.
"private" means the user has RMCDA and "Everyone else" has "none".
"public" means the user has RMCDA and "Everyone else" has R
"custom" is the way DOORS displays a view that has its access altered.
If you auto-inherit all the views than users could change the policy views you have put in there for everyone to read. Your script will want to somehow exclude them, so those views remain unchanged. I'm trying to enforce a policy where Project approved views start with an Upper case letter, and individual folk's view start with the lower-case user name.
|
|
Re: inherit access from parent setting for views
kbmurphy - Tue Oct 04 12:27:52 EDT 2011 llandale - Tue Oct 04 12:02:16 EDT 2011
The clumsy "private" or "public" or "custom" settings are yes inadequate. When someone saves a new view they should immediately manage views, get that view, and adjust its accesses, usually adding the DB and Project admins. But they could also set it to be inherited.
"private" means the user has RMCDA and "Everyone else" has "none".
"public" means the user has RMCDA and "Everyone else" has R
"custom" is the way DOORS displays a view that has its access altered.
If you auto-inherit all the views than users could change the policy views you have put in there for everyone to read. Your script will want to somehow exclude them, so those views remain unchanged. I'm trying to enforce a policy where Project approved views start with an Upper case letter, and individual folk's view start with the lower-case user name.
|
|